IBIS Macromodel Task Group Meeting date: 01 November 2016 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Mike LaBonte noted that he will be unable to attend the next two ATM meetings because he will be at the IBIS summits in Asia. ------------- Review of ARs: - Walter to scrub the IBIS spec and prepare a BIRD for the proposed relaxation of file name rules. - Done. An email with proposed language was sent to ATM on Wednesday, October 26th. - Michael Mirmak to draft a clarification BIRD for AMI Output parameters. - Done. An email was sent to ATM on November 1st. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Michael M.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Relaxation of IBIS filename restrictions: - Walter: [sharing the most recent proposal email] - Modifications to original version (some based on the last meeting's discussions): - File name length was originally bumped from 40 to 80. - Added a TBD item, should we bump it to 128 or 256? - A corresponding increase in the line length would be required. - Added a link to a wiki page on case preservation, to illustrate the well defined notion of "case preserving." - Reduced the character sequences that are not permitted to "//" and "..". - Arpad/Radek: Why exclude "//"? - Radek: It is normally simply treated as "/". - Walter: I left it out because it sometimes implies an absolute path. - We can think about and discuss that one. - New statement: "As a result of this change, 'file' shall mean the file name, including the full path relative to the directory containing the parent file." - Arpad: I think "full" is confusing in that context (may be confused with absolute). - Walter: [removed full from the sentence, based on Arpad's comment] - Examples: [reviewing examples provided in the email] - [Algorithmic Model] example: - .ami and .dll file names containing paths relative to the directory containing the .ibs file. - [Interconnect Model Set Selector] example: - Entries in the selector contain .ims files with paths relative to the directory containing the .ibs file. - The .ims files themselves contain File_TS entries that include paths relative to the directory containing the .ims file. - Discussion: Radek noted that Walter's examples showed the file name entries in each particular file as relative to that file's directory. Radek said he would prefer that the file name entries were always relative to the directory containing the top level .ibs file. Walter said he preferred the hierarchical approach where file name entries in each file were relative to the directory containing the file. He said this would make it easier to have self-contained subdirectories that could be moved around independently and used with multiple top level files (for example, a self-contained set of of Interconnect Models in a subdirectory). Walter said he and Radek could think about this and discuss it further. Bob noted that he wanted the [File Name] keyword entries themselves to remain file name only (no path information). He noted that the .pkg format specification said that .pkg files had to be in the same directory as the .ibs file. Walter said this proposal would not alter that section. Bob noted that a .ebd file in the top level directory containing the .ibs file could itself refer to a .ibs file which would be in a subdirectory. He noted that we have to be careful about situations this proposal might allow, but that he thought it was a good proposal in general. Bob asked that the wiki link entry be removed, and the definition of case preserving be provided in the spec. Walter agreed. Walter took the AR to draft this proposal into a formal BIRD syntax for further review in ATM. Format and Usage Out Clarifications BIRD: - Michael M.: [Sharing initial Draft of the BIRD] - BIRD constructed in response to ibischk BUG 182, which I filed regarding the the relationship between Format and Usage Out. - In IBIS Section 10.3, most of the Format text is written in the context of Usage In. In some cases, In and InOut are explicitly mentioned, but in most cases In is implied. - That caused confusion for me when working with models that had parameters declared as Usage Out, but the nature of Format requires a Value or some additional argument. - Rather than propose changing requirements or making things optional, I opted to instead try to clarify what is expected when a parameter has Usage Out and certain Format settings. - There are a few changes that are non-editorial, in which I've tried to clarify what would happen when an EDA tool sees a model that has Usage Out and Format. This seems ambiguous enough now that different EDA tools behave differently. - About half the changes here are simply editorial or adding explanatory text to make complete sentences. - The opening lines, which attempted to clarify some technical assumptions, may be incorrect based on email feedback I've seen. - The intent of this was not to change anything technical about the parser or the specification, but we may need to review some assumptions. - Discussion: The proposed initial sentence of the Format section: "Format defines the context or arrangement of the data being passed to the executable model file by the EDA tool." and the fifth sentence: "Unless otherwise noted, specific Usage Out arguments or data provided as Format are effectively ignored and will be simply passed by the EDA tool to the executable model file." were both considered unacceptable. Radek pointed out that the Format info might be useful to the EDA tool for an Out parameter, or even necessary in the case of Format Table, but that it is not passed to the model. Walter pointed out that passing an Out parameter to the executable model is actually forbidden (in page 202 of IBIS 6.1, language explicitly restricts the content of the input parameters string to In and InOut only). It was noted that Format Range might provide useful information to the tool. Michael M. asked if there was anything about the contents of Value for an Output parameter that would be useful for the EDA tool or the model. Walter and Radek agreed that if Usage is Out, the contents of Value is totally ignored by both the EDA tool and the executable. (note: Default was also included in the discussion, but Default is expressly forbidden for Usage Out by the spec.) - Michael M.: If I take out mention of the data or content as being "passed to" the executable model for Usage Out, and restrict this to the statements about Format being used by the EDA tool to determine how to display Out parameter data to the user, would that be sufficient? - Walter: Yes. - Michael M.: For Usage In or InOut, I think there's an implication that the parser could do some consistency checking. - For Usage Out, the parser can't check anything (can't check values returned by the model at run time). However, there is an implication that the EDA tool could check returned values (vs. a Format Range, for example). - Radek: Yes, the parser can't test Out parameters. - If the executable model is not following its own rules from the .ami file (for example violating the Range specified in the .ami), I don't think we need to require the EDA tool to report it. - Arpad: I agree that we shouldn't require it, but we could suggest it. - Curtis: Motion to adjourn. - Radek: Second. - Arpad: Thank you all for joining. AR: Walter to put the file name relaxation proposal into a BIRD format. AR: Michael M. to update his BIRD draft based on the discussion. ------------- Next meeting: 08 November 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives